Claims 27-31, 34-37 and 47-52 stand rejected under 35 U.S.C, § 102 as being 
allegedly anticipated Rackson et ah , U.S. Patent No. 5,823,935 ("Racksgn"). Claims 
31-33 are rejected under 35 U.S.C. § 103 as allegedly unpatentable over Rackson in 
view of Robinson et aL U.S. Patent No. 6,415,270 ("Robinson"). Claims 38-43 are 
rejected under 35 U.S.C. § 103 as allegedly unpatentable over Rackson . Claims 44-46 
are rejected under 35 U.S.C. § 103 as allegedly unpatentable over Rackson in view of 
Strickland et aL U.S. Patent No. 5,956,024 ("Strickland"). These rejections are 
respectfully traversed because the cited references do not show the elements of the 
claimed invention as maintained in the Official Action. 

Considered generally, the system described in the present application provides 
tools for managing auction accounts that allow sellers to easily create auction 
submissions by combining stored resources including inventory records, image records 
and predefined advertisement templates. The system also provides a consolidated 
auction monitoring report that automatically tracks the seller's auctions and displays 
updated auction monitoring information. The system further monitors and displays the 
status of post-sale activity, such as shipping, billing, and payment. The system also 
automatically implements certain post-sale functions, such as providing buyer feedback. 
None of the cited references address the problems faced by auction sellers or provide 
any of the auction management tools described and claimed in the present application. 
Applicant therefore respectfully submits that the cited references do not disclose to 
suggest the invention claimed in the present application because the claimed invention 
solves a different problem that is not addressed by any of the cited references. 

In particular, Rackson does not describe any details pertaining to the creation of 
auction submissions, but merely lists some of the elements that might be included in an 
auction submission. Rackson at column 9, lines 25-25. This listing does not suggest 
the creation of auction submissions using stored resources and predefined 
advertisement templates. Moreover, Rackson only describes a reporting interface 
containing information about an item that the user is attempting to purchase at an 
optimal price. See Rackson at Figure 14. This does not suggest creating and updating 
a consolidated auction monitoring report pertaining to items that the user has offered for 
sale at auction. Nor does Rackson suggest the display of tracking items indicating 
post-sale activity or the automatic implementation of post-sale activity. 
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Amendment to Claim 27 

Applicant has amended claim 27 to include the subject matter previously recited 
in claim 28 to more clearly define the claimed invention over the cited references. 
Claim 27 originally recited steps associated with creating auction submissions using 
stored resources and predefined advertisement templates, and claim 28 originally 
recited creating and updating a consolidated auction monitoring report associated with 
the auction submissions. The combined subject matter of these claims now appears in 
claim 27, as amended. Applicant points out that Rackson does not show or suggest a 
system for creating auction submissions using stored resources and predefined 
advertisement templates. Nor does Rackson show a system for creating and updating 
a consolidated auction monitoring report associated with auction submissions created in 
the recited manner. Accordingly, claim 27 is not anticipated or suggested by Rackson . 

Claim 27 has also been amended to recite that the auction submissions and 
consolidated auction monitoring report pertain to items offered for sale by the user. The 
auction monitoring report (Figure 14) disclosed by Rackson , on the other hand, only 
pertains to a single item that the user is attempting to purchase at an optimal price. In 
particular, the input panel shown in Figure 12 of Rackson is used to specify a particular 
type item to be purchased, the quantity of this item desired, information already known 
about this item, and the bid strategy that the user would like to implement. This 
objective is clearly stated in the specification, w a user interface 400 is provided for the 
bidder to describe parameters of the items to be purchased (see Fig. 12)." Rackson . 
coL 24, lines 6-8. The flow chart shown on Figure 13 then describes the process by 
which the information entered into interface 400 (Figure 12) is used to compute and 
place "optimal bids" for the desired item. See Rackson . col. 24, lines 57-8 ("Once the 
bidder defines the item(s) to be bid upon at step 600 [i.e., by entering the data specified 
on Figure 12], the multi-auction service.. .[implements the bid]...") In order to place the 
bid, the system computes an "optimum bid" for the specified item (step 612), 
determines the desired auction site on which to post the optimum bid (step 650), and 
places the optimum bid on the desired site (654). The auction sites are then monitored 
(steps 630, 640) and the bid may be changed while the auctions are in process through 
the iterative loop described in steps 630-654. 

» 
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Figure 14, in turn, is an interface for reporting the status of the bidding process to 
the user, who (as described above) is among the bidders attempting to purchase the 
desired item. To accomplish this objective, this interface 500 displays information 
pertaining to multiple auctions 526 in which the same type of desired item is offered for 
sale. The particular desired item is described in the item description 502 and the Rules 
in Force 510. The user's current bid is pointed out with an asterisk (*) in column 540. 
See, Rackson , col. 25, line 57 - col. 26, line 2: 

For example, an Internet-based interface 500 may be provided for the 
bidder 8 such that the bidder (Jon) can view his selected item type 502, 
and the rules in force 510 and the selected remote auction service items 
520 being tracked (see FIG. 14). 

Thus, the Rackson patent (and Figures 12-14 in particular) only discloses a 
reporting interface (Figure 14) for a multi-auction process for placing an "optimal bid" for 
an item that the user is trying to purchase, and does not disclose any interface for 
monitoring the status of items that the user is attempting to sell. In contrast to the 
system described in Rackson . claim 27 is directed to an auction management system 
that produces a consolidated auction monitoring report that allows a seller to easily 
track and review the status of auctions for items which the user has offered for sale at 
auction. And as noted previously, claim 27 is also directed to a system for creating 
auction submissions using stored resources and predefined advertisement templates, 
which is not shown or suggested in any of the cited references. These differences are 
very clearly recited in claim 27, as amended. 

Rejection of Claims 27-31, 34-37 and 47-52 based on Rackson 

Paragraph 7 the Official Action contends that Rackson shows the steps of claims 
27-31 , 34-37 and 47-52. The examiner's explanation starts by claiming that Figure 4 of 
Rackson shows the step of "creating an auction consolidation account." But there is no 
such step shown on Figure 4 of the Rackson patent. Rather, Figure 4 of Rackson 
shows a process in which a seller offers an item for sale through a multi-auction 
service. There is no step suggesting the creation of an account of any type, nor is there 
any suggestion of an account that could be considered an "auction consolidation 
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account," Rather, as described above, the Rackson patent is primarily concerned with 
computing an optimal price for an item that the user would like to purchase. Therefore, 
Rackson does not describe or suggest the creation of an "auction consolidation 
account" associated with items that user has offered for sale at auction, as recited in 
claim 27 of the present application. 

The Official Action also contends that Figure 4 and column 9, lines 5-50 of 
Rackson show the step of receiving and storing a library of inventory records, image 
records and advertisement templates. But Figure 4 and column 9, lines 5-50 of 
Rackson do not show or suggest any libraries of stored resources for creating auction 
submissions or advertisement templates of any description. Instead, Rackson at 
column 9 merely lists the parameters that may be Included in a submission to the multi- 
auction service. See, in particular, Rackson at column 9, lines 25-25, which states the 
list of selling parameters: 

The seller or the multi-auction service may specify the selling parameters 
of the offer to include, but are not limited to, some or all of the following: 
starting date and time; closing date and time; reserve price; a successful 
bid range; quantity of items; item description which may comprise in 
addition to text, graphic representation such as image file, photograph; 
audio file; video clip or other content that provides a representation of the 
item. These parameters may be defined by the seller with assistance by 
the multi-auction service or may be generated exclusively by the multi- 
auction service. 

This passage does not disclose or suggest a library of inventory records, image records 
and advertisement templates. In fact, advertising templates are not even mentioned. 
Moreover, Rackson only describes receiving the listed information and does not 
suggest how the information might be stored for subsequent use. There is no 
suggestion of creating libraries to store resources such as inventory records, image 
records and advertisement templates. 

The Official Action also contends that Figures 3, 4 and 10 along with column 9, 
lines 5-50 of Rackson show the step of combining an inventory record, an Image record 
and advertisement template to create an auction submission. But this is simply not the 
case. Figure 3 is a block diagram, Figure 4 is a flow chart of a process in which a seller 
offers an item for sale through a multi-auction service, and Figure 10 is another block 
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diagram. As noted above, column 9 of Rackson merely lists selling parameters. None 
of the cited sections of Rackson show or suggest any type of advertisement template or 
any process that combines stored elements with a predefined advertisement template 
to create an auction submission. 

The Official Action also contends that Figures 3 ( 4 and 10 of Rackson show the 
step of storing the auction submission in a library in association with an account. Again, 
this in not the case. None of the cited figures show a library storing auction 
submissions, and they certainly do not show a library storing auction submissions 
created by combining an advertisement template with other stored resources as recited 
in claim 27 of the present application. Rather, Figures 3, 4 and 10 of Rackson are 
general block diagram that do not show any details concerning the type or format of 
data stored in the computer storage devices. 

The Official Action further contends that Figures 3, 4 and 10 and col. 8, lines 5- 
17 of Rackson show the step of transmitting the auction submission to one or more 
sites in accordance with, the auction parameters. Although Figure 3 and col. 8, lines 5- 
17 of Rackson does describe the transmission of an auction submission to multiple 
auction sites, it does not describe the transmission of an auction submission created in 
the matter recited in claim 27 of the subject application. Specifically, the auction 
submission described in Rackson is not created by combining a predefined 
advertisement template with other stored resources (i.e., inventory record and image 
record) as recited in claim 27 of the present application. 

The Official Action further contends that Figure 14 and column/line 24/5-25/35 
and col. 26, lines 21-28 of Rackson show the step of compiling a consolidated auction 
monitoring report. Although Figure 14 and the cited passages in Rackson do show the 
creation of an auction monitoring report, this report does not consolidate information 
associated with auction submissions created in the manner recited in claim 27 of the 
subject application. Moreover, Figure 14 of the Rackson patent only displays 
information associated with an "optimal bid" for an item that the user is trying to 
purchase , and does not compile information related to items that the user is attempting 
to sell as recited in claim 27 of the present application. 

The Official Action further states that Rackson shows several other elements of 
the claimed invention including revisiting each auction site to extract update information, 
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repeatedly constructing auction submissions, and so forth. Although Rackson does 
disclose similar features in connection with tracking an item for purchaser, it does not 
disclose the execution of these features in connection with auction submissions posting 
items for sale, or for auction submissions created by combining stored resources and 
advertisement templates, as recited in claim 27 of the subject application. 

Accordingly, Applicant respectfully submits that Rackson does not anticipate 
claims 27-31, 34-37 and 47-52 of the present application and cannot establish a prima 
facie case of obviousness for this invention because it does not show or suggest each 
element of the claimed invention. MPEP § 2143.03. 

Rejection of Claims 31-33 based on Rackson in view of Robinson et al. 

Paragraph 8 of the Official Action rejects claim 31-33 under 35 U.S.C. 103(a) as 
allegedly unpatentable over Rackson in view of Robinson. et al. It should initially be 
noted that claims 31-33 depend from claim 27 and are, therefore, patentable for the 
reasons stated above with reference to claim 27. In addition, claims 31-33 add further 
elements directed to creating and storing or transmitting a billing record, a sales record, 
payment information and shipping information in connection with the auction 
consolidation account. The Official Action admits that Rackson does not show these 
features but claims that Robinson et al. does. But Robinson et al. merely describes the 
creation of an encrypted digital sales receipt in connection with an electronic 
transaction and does not show or suggest the inclusion of a billing record, sales record, 
payment information or shipping information in connection with an auction consolidation 
account. See the Abstract of Robinson et al. 

Robinson et al. also fails to describe the content of the sales receipt and, 
therefore, does not show or suggest the inclusion of any specific Information, such as 
shipping information, in an auction consolidation account. Robinson et al. also fails to 
describe any motivation for combining an electronic sales receipt with the system 
disclosed In the Rackson patent. Rather, the combination is not motivated because the 
electronic sales receipt described in Robinson et al. would be superfluous in the multi- 
auction service described in Rackson in view of the interface shown in Figure 14 of 
Rackson for displaying information associated with an item that the user is attempting 
to purchase. Although the Official Action claims that it would have been obvious to 
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combine the electronic sales receipt of Robinson et al. with the interface shown in 
Figure 14 of Rackson "in order to authenticate an electronic transaction by providing 
both parties with an accurate and secure record of the transaction" this has no bearing 
on the present application, which does not address authentication or security of 
transactions. Rather, the present application is concerned with facilitating the 
management of auctions, which has nothing to do with the encryption system described 
in Robinson et al 

Moreover, the combination of Rackson and Robinson et al. would not cerate the 
invention of claims 31-33 because neither reference shows or suggests the creation of 
an auction submission by combining stored resources* such as an inventory record and 
an image record, with a predefined advertisement template. Accordingly, the 
combination of Rackson and Robinson et al. does not establish a prima facie case of 
obviousness for invention recited in claims 31-33 of the present application because 
each element of the claimed invention is not shown or suggested in one of the 
references. MPEP § 2143.03. 

Rejection of Claims 39-43 Based on Rackson 

Claims 38-43 are rejected based on Rackson alone. Because claims 39-43 
depend from claim 27, this rejection was addressed previously with reference to claim 
27, Moreover, Rackson does not show the various features recited in claims 38-43, 
and Rackson does not show a comprehensive system for reporting auction status as 
claimed in the Official Action. Rather, as noted previously, Figure 14 of Rackson only 
shows a report concerning an optimal bid for an item that the user would like to 
purchase. It does not show or suggest consolidated reporting for multiple items the 
user has offered for sale. Nor does Rackson show or suggest automatically 
implementing post-sale activity, such as sending a notice of the auction closing in a 
manner specified in a record associated with the account, as recite in claim 41 of the 
present application. 

Further, claim 42 recites additional automatic post-sale activity including notifying 
a selling party of the sale, notifying the buying party of the sale, and creating a sales 
record documenting the auction closing. Rackson does not show or suggest these 
elements. In addition, claim 43 recites even more automatic post-sale activity, including 
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obtaining an automatic feedback instruction from settings data associated with the 
corresponding account and transmitting auction feedback data to the corresponding site 
in accordance with the automatic feedback instruction. Again, Rackson does not show 
or suggest these elements. 

The examiner's contention that the post-sale activity elements recited in claims 
41-43 are suggested by Rackson is unsupported by the cited sections of the reference 
(i.e., Figures 12-14 and associated column and line citations), which merely describe 
the processes and features associated with the interface shown in Figure 14 of 
Rackson for displaying information associated with an item that the user is attempting 
to purchase at an optimal bid. These sections of Rackson do not show or suggest any 
type of post-sale activity, such as the claimed features of notifying a selling party of the 
sale, notifying the buying party of the sale, creating a sales record documenting the 
auction closing, and obtaining an automatic feedback instruction from settings data 
associated with the corresponding account and transmitting the auction feedback. 
Accordingly, Rackson cannot establish a prima facie case of obviousness for the 
invention recited in claims 39-43 of the present application because each element of 
the claimed invention is not shown or suggested in this reference. MPEP § 2143.03. 

Rejection of Claim 44-46 based on Rackson In view of Strickland et al. 

Paragraph 1 1 of the Official Action rejects claims 44-46 as being unpatentable 
over Rackson in view of Strickland et al. These claims are directed to the use of action 
tracking fields in the consolidated auction monitoring report to indicate the status of 
certain tasks associated with managing auctions, such as buyer notification, payment 
received, auction item shipped, and payment received. The Official Action contends 
that Figure 1 of Strickland et al. shows a customer management interface for tracking 
parameters such as payment status, buyer notification and delivery status. But this 
contention is incorrect. Figure 1 of Strickland et al, actually shows a graphical user 
interface in which each icon represents a function that is activated by clicking on the 
associated icon. See Strickland et al. at col. 3, lines 4-9. Moreover, the specific 
graphical user interface as described in Strickland et al. . which is used by customer 
service representatives for subscriber management systems, does not show or suggest 
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the receipt and display of user input into auction tracking fields in an auction monitoring 
report, as recited in claim 44 of the present application. 

Further, the combination of Rackson and Strickland et aL does not show or 
suggest the use of action tracking fields in a consolidated auction monitoring report to 
indicate the status of post-sale tasks associated with managing auctions, such as buyer 
notification, payment received, auction item shipped, and payment received as recited 
in claim 45 of the present application. Nor does the combination of Rackson and 
Strickland et aL show or suggest automatically implementing post-sale functions by 
obtaining an auction processing instruction from settings data associated with the 
corresponding account, performing an operation in accordance with the auction 
processing instruction; and setting one of the tracking field to indicate completion of the 
operation, as recited in claim 46 of the present application. Accordingly, the 
combination of Rackson and Strickland et aL does not establish a prima facie case of 
obviousness for invention recited in claims 44-46 of the present application. MPEP § 
2143.03. 



It is believed that the preceding remarks are completely responsive to the Official 
Action mailed May 5, 2004, and that the claims are in condition for allowance. If the 
Examiner believes that there are any issues that can be resolved by a telephone 
conference, or that there are any informalities that can be corrected by an Examiner's 
amendment, please call Mike Mehrman at (404) 497-7400. 



Mehrman Law Office, P.C. 
5605 Glenridge Drive, Suite 795 
Atlanta, GA 30342 
404 497 7400 telephone 
404 497 7405 facsimile 
mike@mehrmanlaw.com 
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By: Michael J. Mehrman 
Reg, No. 40,086 
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